While I agree that typically a single user will use viking on a
computer, I think it should remain clean with respect to ${prefix}/share
not being modified, $etcdir being system-wide config, and ~/.viking for
per-user config.
In pkgsrc, the distribution default maps.xml would be put in
/usr/pkg/share/examples/viking/maps.xml ($egdir), and then treated as
the default value of /usr/pkg/etc/viking/maps.xml (copied to it on first
install, and that file removed if it matched on deinstall). In other
words, share really is for things that don't need changing by users or
machine admins.
Merging the maps.xml makes sense, but perhaps one needs a whiteout
command to drop an entry. OTOH that may be foolish complexity.
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.
I vote for loading/merging maps*.xml from ${etcdir} and ~/.viking.
It makes a lot of sense to have one xml file per map type, for easy
handling.
So I guess the real question is whether having a map known to viking
ever needs overriding. One could say the list can always be made
bigger, and the only question is whether a particular menu list should
show each map. That view says /usr/share/viking/maps.xml is not a
config file, but distribution-defined maps. Then a user would disable
some of them if they were annoying.
My own use case is that I have a gpx.viking file that I prepend to
tracks/waypoints, so I rarely use the 'add map' menu.
pgpsF1LiJAkqx.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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/
