2012/5/2 Evan Battaglia <gtoe...@gmx.net>: > I'm not sure if you meant to email just me or forgot to hit 'reply all' to > email the whole mailing list.
Oups... thanks for the advice. > It doesn't matter too much to me. I think you're right the second options is > slightly better. I'm guessing many people who use viking will be the sole > users of their computers (like I am), so they can edit the /usr/share and > /etc/ files directly themselves. One thing that would be nice would be the > ability to use the global maps.xml file without doing a make install (i.e. > it looks in the directory relative to where it is), but even that isn't > really necessary, since I or a user can just copy it into his > ~/.viking/maps.xml directory. It would be good to try and give as much > visibility about this file as possible, though. Humh, I do not really like the idea to load a local file silently. But perhaps I'm wrong. What do you think about adding a command line option to: - specify a single .xml file - specify a config directory I think the second option is better and probably cover your expected use case. A related question is "What is the precedence of the file specified in command line?" I think common usage expect that command line option are prior than $HOME config files, prior than /etc prior than /usr/share. Other idea is to add a VIKING_CONFIG_PATH variable environment. If unset, built-in configuration path is $HOME/.viking:/etc/viking:/usr/shar/viking. If set, the built-in is not used and only the specified path are used. But perhaps should we ALWAYS process the $HOME/.viking even when VIKING_CONFIG_PATH is set. > On Tue, May 1, 2012 at 11:50 AM, Guilhem Bonnefille > <guilhem.bonnefi...@gmail.com> wrote: >> >> 2012/5/1 Evan Battaglia <gtoe...@gmx.net>: >> >> You do not have to credit me on the two new files, they are yours. :-) >> > Yeah, I just copy and paste files and don't give much thought to >> > copyright >> > notices :) >> > >> > I wasn't aware of the maps.xml file, but it is truly awesome, especially >> > given how so many services use that same mercator >> > OSM/slippymap/whatever-it's-called scheme. And great that users of >> > today's >> > versions of viking can use CalTopo just by editing that. >> > >> > >> >> In one hand, it seems to be a usefull freely >> >> available map. In the other hand, this is USA only related. Perhaps >> >> the hability to configure it is enough? >> > I strongly advocate built-in support for topos, even if they are >> > USA-only. >> > Sure, I live in the USA, but hear me out: my main use of Viking is with >> > topos, and I suspect there are many others who are the same way (for >> > instance, a long long time ago, Reid Priedhorsky made some topo maps for >> > an >> > Escalante hiking trip with Viking). There is a big market for making >> > your >> > own custom topos: National Geographic TOPO >> > (http://www.natgeomaps.com/topo_state.html ) sells for a ridiculous >> > amount >> > of money (like $50 for each state!), and there is also TopoFusion. And >> > we >> > can compete here. If Viking (as installed I have a preference by >> > 'apt-get install viking' in >> >> > Ubuntu) comes shipped with support to make your own topo maps, I think >> > it >> > would increase the visibility and really show people what Viking can do. >> > (I'm assuming the debian package is compiled with the default options). >> > I >> > don't think the one extra item in the menu that users from other >> > countries >> > may never use hurts much. If there were a really good Topo map source >> > for >> > only France or New Zealand or something, I wouldn't object to having it >> > built-in, in fact I might be curious to see what the maps look like... >> > and >> > there are already tons of map sources compiled in that I don't use... >> > >> > Anyway, it does seem strange to me that I would have to add new code to >> > get >> > CalTopo in; I guess there's no global "maps.xml" file? >> >> You're definitively right: this was a old open item on my todo list >> since I added maps.xml feature. I imagine to put some files in >> standard locations: >> - /usr/share/viking/maps.xml (or something like that, depending on >> distribution) >> - /etc/viking/maps.xml >> Classicaly, the main difference is that /etc/viking/maps.xml is >> editable by admin while /usr/share/viking/maps.xml is supposed to stay >> untouched, only deployed by package. >> >> But a question remains: what logic should we implement to offer >> maximum power to user. >> >> First logic: we only load a single file, the first one found: >> - $HOME/.viking/maps.xml >> - /etc/viking/maps.xml >> - /usr/share/viking/maps.xml >> This logic allows the user to overwrite all settings, keeping only the >> most interesting for him. >> >> Second logic: we load all files. The current internal management allow >> to overwrite existing ids with new definitions. >> The matter with this logic is that the list of supported maps provider >> can be very long. In the other hand, this will allow the user to >> discover new maps when upgrading the package, even if he already >> defined a personnal maps.xml. >> >> I'm not sure about the right option. And perhaps there is other >> options. I think the second one is better. >> >> And I imagine we can go further: load more than one file per >> directory. For example, load maps.xml + maps_*.xml (or *_maps.xml). >> Why? In order to allow packaging all map source in different files and >> different package (one per country, for example viking-data-us.deb). >> This way, the packagers and users will have lot of power with few >> effort. >> >> >> Any comment appreciated. I'm available to do such changes, but I need >> a direction. >> -- >> Guilhem BONNEFILLE >> -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com >> -=- mailto:guilhem.bonnefi...@gmail.com >> -=- http://nathguil.free.fr/ > > -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
