> > 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.
My 2p or 2cents (American or Euro) .... Since Viking is a desktop program, to me that means it is effectively is for the sole user of the that machine. However, it could best to move all current code definitions of maps into a central maps.xml - and then load in your own maps.xml afterwards. 1. This simplifies the code as Evan notes 2. It's 'easier' to add new ones for developers. 3. The end user can remove any one they don't want to use by editing the system file. 4. The end user can override the system ones if they choose to with their own config. Checking each of XDG_DATA_DIRS for /viking/maps.xml files See: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Albeit there still needs some way of choosing the default - e.g. Mapquest entry - but if not there - then use the first in the list of available maps. > 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. > This seems a lot of complexity, just load a couple of files in a predefined order - system ones then user ones. It would be really good (for the end user) if one could edit/reload the map configuration from within Viking itself, without having to fiddle with text file configurations directly. Not that I'm volunteering to write such code :) But this should make it *much more* obvious the default maps can be changed. However I suspect most people who use Viking would be capable of fiddling with their maps.xml (and probably know of this possibility or find out via the Wiki) Viking is *not* that simple to use - especially for new users ( I won't go into it's shortfalls ATM - perhaps I should write a blog post... ) Maybe we should just stick CalTopo in - as in USA is important (large population + probably many Viking users). Whether that's via code - as it is the more expedient way or via a future deployed maps.xml (or maps-us.xml etc..) Only if anyone else expresses an interest, would I think it's worth trying to do 'VIKING_CONFIG_PATH' or command line options (not that I expect many desktop users to invoke Viking via the command line). ------------------------------------------------------------------------------ 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/
