[Gvsig_english] Recent change for gvSIG 1.10 in SVN
Benjamin Ducke
benjamin.ducke at oxfordarch.co.uk
Mon Jul 12 10:35:47 CEST 2010
OK. I have committed a patchset to the SVN and linked the
the new ticket to the one below.
I turned out that the whole thing was a bit more complicated,
because I had to go through every single extension and make sure
that they respect the global setting for the user folder location
(most of them don't). I hope I got them all, but I gave it some
extensive testing and it all worked very well. The only problem is
that the symbology extension does not take care of creating the
default styles and symbols if they are not in the user folder.
Apparently, this is done only once, by the setup program.
The solution for the time being is to use a script that takes
care of putting sensible defaults into the user settings folder
before starting up gvSIG.
I have attached a Linux and a Windows script to this message to
demonstrate how all this can be done. They are part of the next
release of gvSIG OADE 2010, which will be released in a few
days.
Cheers,
Ben
----- Original Message -----
> +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
>
> _______________________________________________ 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gvSIG.sh
Type: application/x-shellscript
Size: 2145 bytes
Desc: not available
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100712/7a8606a5/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gvSIG.bat
Type: application/x-msdos-program
Size: 1074 bytes
Desc: not available
Url : http://listserv.gva.es/pipermail/gvsig_internacional/attachments/20100712/7a8606a5/attachment.bat
More information about the Gvsig_internacional
mailing list