Hi, In few words: really exciting roadmap. I'm imprssed by the volume of the changes you already have on private branches.
Some personnal thoughts inside text. 2012/12/8 Robert Norris <rw_nor...@hotmail.com>: > = Some Thoughts on Viking 1.4 and Beyond = > > * Upgrade sourceforge website to be the Allure platform - looks like > everything we use should automigrate now? > [MediaWiki should auto convert... (still I'll keep backups!)] > > * Integrate together my provisional work in > https://github.com/rnorris/viking for a 1.4 release. > > * This is your chance to provide feedback about / test these features over > the Christmas and New Year period. > > * Consider whether version 1.5 or 2.0 will follow much later in the year... > > = 1.4 version - January 2013 = > > * GPS Layer now uses a string for the Device Id rather than a number [1] > (Branch: GPX-Route+Icons+Colour[2]) > > * GPX Route Support [1] (Branch: GPX-Route+Icons+Colour [2]) > > * TrackWaypoint Layer changes [1]: (in git master already) > ** changes to Draw by Velocity mode parameters > ** addition of waypoint font size > ** addition of trackpoint size control > ** addition of track arrows and arrow size control > > * Store a version number in the .vik file type [1] (Branch: > StagingPatches[2]) > ** small warning when loading an unsupported version > > * Start Assist for new users with some default settings [simple on/off > preference] > ** Single default map / location by www.hostip.info / auto download on > ** Defaults to on for 'first time users' (if you already have Viking > installed[2] then the mode defaults to off) I'm not sure using a web service is a really good gift to users. What about using geoip libraries (package called libgeoip1 on my Debian)? > * Datasource 'My OSM Traces' (Branch: DatasourceRework+NewMyOSMTraces[2]) > > * Optimizations (Branch: OptimusPrime[2]) > > * [1] Not forwards compatible - Viking <1.3 won't be able to read new files > fully but IMHO fairly minor inconvenience > * [2] See https://github.com/rnorris/viking > * [3] Detection is via having an existing .viking/prefs file > > = 1.5 = > > * Undo (I have some working ideas on how to do this) Great! > * Switch to outputting Title Case Waypoint Symbols in GPX ( but for .vik > files always lowercase ) > ** Symbol table to be in Title Case (as per Sven Eckelmann's work from 2 > years ago - which still can read in lower case symbols) > ** Probably should store waypoint symbol index in VikWaypoint and only > calculate this 'once' rather than doing the hash lookup on each redraw in > viktrwlayer.c > *** As I don't think the icon index changes during the lifetime of the > program. Only change wp symbol index when the symbol is changed. Might push > this into the optimizations for 1.4 > > * Other stuff as seen fit > > = 2.0 = > > Full Version number jump due to incompatibilities between 1.X and 2.0. > > The question is when to discontinue the 1.X line, maybe not even bothering > with a 1.5 version??? > Opinions gratefully accepted. > > Version 2.0 should work with previous versions file data. 1.X will *NOT* be > able to use any Viking 2.0 specifics: > > * Internal auto preferences/last used values > > * New version number in the .vik file type > > * Compressed (but still humanly readable) for common keys in a .vik file > ** This can save around 1/4 file space as for a simple GPS track log these > are repeated for *every* trackpoint > *** 'latitude' -> 'lat' > *** 'longitude' -> 'lon' > *** 'trackpoint'->'trkpt' > *** 'altitude'->'alt' > *** 'unixtime'->'UTC' (http://en.wikipedia.org/wiki/Unix_time) > *** maybe write float values as 9 decimal digit precision (as this is what > comes out of GPSBabel) (see SF# Viking shouldn't change coords) > *** [see if we can round display of altitude to whole numbers when practical > - '123.000000' doesn't look nice] > ** Keep the old GPS Point export saving at 'version 1' with full key names > (although I don't know any other software that uses this format...) > ** Internal option to write .vik file at version 1 ? > > * As per request: SF#3023287 > ** Shift of map cache data default to $XDG_CACHE_HOME and file structure to > match standard OSM <TileServerRef>/zoom/x/y.png file name > *** Should mean you could sym link this cache other programs cache areas > (e.g. TangoGPS / Marble? / JOSM? ) > *** Maybe make the 'Maps Directory' use directly the zoom/x/y when manually > specified - so one can point it at a shared cache directory > **** (But when using the default <TileServerRef> and you can the map type > the map directory auto uses the correct <TileServerRef>) > ** Move ~/.viking/ to $XDG_CONFIG_HOME > *** Will provide a Python script to convert the map cache from 1.X scheme > <-> 2.0 layout As precised in SF#3023287 I started some work in this direction: http://repo.or.cz/w/viking/guyou.git/shortlog/refs/heads/viking-gnome > * Fix some Waypoint symbol names: > ** 'scenic' -> 'Scenic Area' > ** 'white buoy' -> 'Buoy, White' > *** Hopefully can work out a way to read from old files / auto convert / but > don't show both symbols in symbol selection -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
