[Gvsig_english] Recent change for gvSIG 1.10 in SVN

Francisco José Peñarrubia fpenarru at gmail.com
Thu Jul 8 17:29:42 CEST 2010 

+1

This is the ticket if you need it in order to attach the patch.

https://forge.osor.eu/tracker/?func=detail&aid=14411&group_id=89&atid=732

Cheers.

Fran.

Pablo Sanxiao escribió:
> 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
>>     
>
>   

-- 
Fran Peñarrubia
Scolab
www.scolab.es

Asociación gvSIG
www.gvsig.com

More information about the Gvsig_internacional mailing list